Obtain the type object from TypeManager via getType(Re2JRegexpType.RE2J_REGEXP_SIGNATURE) instead of constructing an instance manually.

I've tried to add TypeManager to PlanOptimizers's @Inject constructor and to pass it from there. I had to change ~15 files including tests, but then I got a runtime error since PlanOptimizers is bound at CoordinatorModule, while TypeManager is not bound yet.
I couldn't find another way to obtain TypeManager, any suggestions?

This is what we need to implement this more generically, without having to hardcode any knowledge about how regexp functions work:

protected Optional<Expression> translateCall(Call call)
{
    if (LIKE_FUNCTION_NAME.equals(call.getName())) {
        return translateLike(call.getArguments().get(0), call.getArguments().get(1));
    }

    QualifiedName name = QualifiedName.of(call.getName());
    FunctionCallBuilder builder = new FunctionCallBuilder(metadata)
            .setName(name);

    List<TypeSignature> argumentTypes = call.getArguments().stream()
            .map(argument -> argument.getType().getTypeSignature())
            .collect(toCollection(ArrayList::new));

    ResolvedFunction resolved = metadata.resolveFunction(name, TypeSignatureProvider.fromTypeSignatures(argumentTypes));
    for (int i = 0; i < call.getArguments().size(); i++) {
        Expression expression = ConnectorExpressionTranslator.translate(session, call.getArguments().get(i), metadata, variableMappings, literalEncoder);
        Type expectedType = resolved.getSignature().getArgumentTypes().get(i);
        Type actualType = metadata.getType(argumentTypes.get(i));

        if (!actualType.equals(expectedType)) {
            verify(typeCoercion.canCoerce(actualType, expectedType));
            expression = new Cast(expression, toSqlType(expectedType));
        }

        builder.addArgument(expectedType, expression);
    }

    return Optional.of(builder.build());
}

Thanks!
I just made a single change to your suggestion - replaced if (!actualType.equals(expectedType)) { with if (!typeCoercion.isTypeOnlyCoercion(actualType, expectedType)) { because, for example, at
testCrossJoinLargeBuildSideDynamicFiltering() we get $internal$dynamic_filter_function with a varchar(9) argument while its expectedType = varchar. Is this change ok by you?

In addition, are you aware of an equivalently generic way to implement io.trino.sql.planner.ConnectorExpressionTranslator.SqlToConnectorExpressionTranslator#visitFunctionCall which still refers to JoniRegexp and Re2JRegexp specifically?

This translation can be done inside the if block below.

The translator currently supports many functions.
If I'll do so, I'll need to create a FunctionCall only inside the if, so only regexp_like and LIKE functions will be supported. Therefore, I'll also need to change io.trino.sql.planner.ConnectorExpressionTranslator.SqlToConnectorExpressionTranslator#visitFunctionCall to convert only regexp functions (because otherwise we'll translate only in one direction).
Do you want me to narrow the translation this way?

If connectorExpression is empty (i.e., either there wasn't a expression in the first place or the translation from Expression->ConnectorExpression failed), it is still possible that remainingConnectorExpression is not empty (i.e., if the connector synthesizes an expression). In that case, we need to combine decomposedPredicate.getRemainingExpression() with the result from applyFilter().

Modified

( followed up here: #7994 (comment) )

The conversion

 Optional<ConnectorExpression> connectorExpression = new ConnectorExpressionTranslator.SqlToConnectorExpressionTranslator(session, remainingExpressionTypes, plannerContext)
                .process(decomposedPredicate.getRemainingExpression());

is lossy.

i.e. decomposedPredicate.getRemainingExpression() contains full information
but then connectorExpression contains partial information
remainingConnectorExpression contains part of connectorExpression, so again not a full information
so then translatedExpression cannot supersede remainingDecomposedPredicate

i think SqlToConnectorExpressionTranslator should work like a DomainTranslator, i..e it should spit out (a) translated result and (b) remaining expression

@martint do you have a suggestion how to handle this for now, so that SqlToConnectorExpressionTranslator change can be a follow up?

is lossy.

That should not be the case. The translation should either succeed and be equivalent to the original expression, or fail and return Optional.empty().

Indeed @martint it's not a problem, as it's not lossy.
Although it should be. If a conjunct cannot be translated, we still should push down the others that can. cc @hashhar
But that's something we can follow up on.

@martint Shouldn't this use LikeFunctions#LIKE_PATTERN_FUNCTION_NAME, so that we don't have to re-run DesugarLike?

cc @wendigo